Больше 5 лет назад мы писали о технологии VMware Storage I/O Control (SIOC), которая позволяет приоритизировать ввод-вывод для виртуальных машин в рамках хоста, а также обмен данными хостов ESXi с хранилищами, к которым они подключены. С тех пор многие администраторы применяют SIOC в производственной среде, но не все из них понимают, как именно это работает.

На эту тему компания VMware написала два интересных поста (1 и 2), которые на практических примерах объясняют, как работает SIOC. Итак, например, у нас есть вот такая картинка:

В данном случае мы имеем хранилище, отдающее 8000 операций ввода-вывода в секунду (IOPS), к которому подключены 2 сервера ESXi, на каждом из которых размещено 2 виртуальных машины. Для каждой машины заданы параметры L,S и R, обозначающие Limit, Share и Reservation, соответственно.

Напомним, что:

• Reservation - это минимально гарантированная производительность канала в операциях ввода-вывода (IOPS). Она выделяется машине безусловно (резервируется для данной машины).
• Shares - доля машины в общей полосе всех хостов ESXi.
• Limit - верхний предел в IOPS, которые машина может потреблять.

А теперь давайте посмотрим, как будет распределяться пропускная способность канала к хранилищу. Во-первых, посчитаем, как распределены Shares между машинами:

Общий пул Shares = 1000+2500+500+1000 = 5000

Значит каждая машина может рассчитывать на такой процент канала:

VM1 = 1000/5000 = 20% = 0,2 * 8000 = 1600 IOPS
VM2 = 2500/5000 = 50% = 0,5 * 8000 = 4000 IOPS
VM3 = 500/5000 = 10% = 0,1 * 8000 = 800 IOPS
VM4 = 1000/5000 = 20% = 0,2 * 8000 = 1600 IOPS

Если смотреть с точки зрения хостов, то между ними канал будет поделен следующим образом:

ESX1 = 3500/5000 = 70%
ESX2 = 1500/5000 = 30%

А теперь обратимся к картинке. Допустим у нас машина VM1 простаивает и потребляет только 10 IOPS. В отличие от планировщика, который управляет памятью и ее Shares, планировщик хранилищ (он называется mClock) работает по другому - неиспользуемые иопсы он пускает в дело, несмотря на Reservation у это виртуальной машины. Ведь он в любой момент может выправить ситуацию.

Поэтому у первой машины остаются 1590 IOPS, которые можно отдать другим машинам. В первую очередь, конечно же, они будут распределены на этом хосте ESXi. Смотрим на машину VM2, но у нее есть LIMIT в 5000 IOPS, а она уже получает 4000 IOPS, поэтому ей можно отдать только 1000 IOPS из 1590.

Следовательно, 590 IOPS уйдет на другой хост ESXi, которые там будут поделены в соответствии с Shares виртуальных машин на нем. Таким образом, распределение IOPS по машинам будет таким:

VM1 = 10 IOPS
VM2 = 4000+1000 = 5000 IOPS (так как установлен Limit)
VM3 = 800 + ((500/1500) * 590) = 997 IOPS
VM4 = 1600 + ((1000/1500) * 590) = 1993 IOPS

Все просто и прозрачно. Если машина VM1 начнет запрашивать больше канала, планировщик mClock начнет изменять ситуацию и приведет ее к значениям, описанным выше.

Мы уже писали о возомжностях новой версии Veeam Availability Suite v9, включающей в себя продукты Veeam Backup and Replication 9 и Veeam ONE 9.

Напомним возможности девятой версии флагманского продукта Veeam, о которых мы писали ранее:

• Veeam Explorer для Oracle - поддержка восстановления объектов БД в Veeam Availability Suite v9. Плюс улучшения всех эксплореров
• Интеграция с технологией EMC Storage Snapshots
• Veeam Cloud Connect с возможностью репликации
• Прямой доступ к хранилищам NFS

В этой заметке мы расскажем еще об одной важной новой функции пакета продуктов - Scale-out Backup Repository. Ранее пользователи Veeam Backup and Replication использовали различные устройства для бэкап-репозиториев, чтобы хранить резервные копии виртуальных машин. Это могли быть локальные диски серверов, файловые хранилища, разделы на СХД и многое другое. Так как инфраструктура растет постепенно и, зачастую, неоднородно, в итоге у администраторов оказывался примерно вот такой наборчик бэкап-репозиториев:

Эта картина плоха со всех сторон. Во-первых, таким большим числом репозиториев трудно управлять - надо следить за их доступностью, поддерживать схемы именования, смотреть за свободным пространством и т.п. Все это создает серьезные административные проблемы в большой инфраструктуре.

Во-вторых, число бэкап-задач, которые создает администратор - как минимум равно числу бэкап-репозиториев, так как одна задача не может охватывать 2 репозитория.

Ну и, в третьих, посмотрите на свободное место на каждом репозитории - его весьма много (если брать среднее, то 30%). То есть, мы используем вполовину больше того, что нам требуется.

Эта ситуация давно волновала администраторов, и в новой версии Veeam Availability Suite v9 представлена функция Scale-out Backup Repository, которая позволяет объединить все репозитории в один мета-объект (global pool), который можно задавать в качестве целевого хранилища бэкапов. Для расширения такого пула потребуется лишь добавить экстент (extent), который повысит совокупную емкость глобального репозитория. Удобно и не надо перераспределять целевые хранилища, чтобы найти свободное место под новые бэкапы.

Таким образом, можно использовать единственную задачу резервного копирования всех нужных вам машин, указав в качестве целевого этот глобальный репозиторий. При этом глобальный репозиторий можно наращивать хранилищами любого типа - локальные диски серверов, сетевые хранилища и даже, например, дедуплицирующие физические или виртуальные модули (dedup appliances) - все это для Veeam Backup and Replication будет поддерживаться и работать.

При добавлении экстента можно указать, принимает ли он полные бэкапы (full backups), инкрементальные бэкапы (incremental backups) или оба типа. Например, для инкрементальных бэкапов можно использовать быстрые all-flash хранилища, а для полных бэкапов можно применять dedup appliance в качестве целевого хранилища резервных копий, где они будут лежать в дедуплицированном виде. Возможности для фантазии тут безграничны.

Также происходит, по-сути, появление бэкап-облака, нового уровня абстракции, которое представляется пользователям как единое пространство хранения резервных копий, а его обслуживанием занимается бэкап-администратор. Теперь владельцы систем могут сами настраивать бэкап своих виртуальных машин в единое облако, не думая, какой репозиторий выбрать, а бэкап-администратор уже займется оптимизацией своего облака.

Более подробно об этом всем написано в блоге Veeam.

Бывает так, что на виртуальной или физической машине заканчивается свободное место на диске, где расположена база данных для VMware vCenter. Чаще всего причина проста - когда-то давно кто-то не рассчитал размер выделенного дискового пространства для сервера, где установлен vCenter и SQL Server Express.

В этом случае в логах (в SQL Event Log Viewer и SQL Log) будут такие ошибки:

Could not allocate space for object ‘dbo.VPX_EVENT_ARG’.’PK_VPX_EVENT_ARG’ in database ‘VIM_VCDB’ because the ‘PRIMARY’ filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

CREATE DATABASE or ALTER DATABASE failed because the resulting cumulative database size would exceed your licensed limit of 4096 MB per database.

Could not allocate space for object 'dbo.VE_event_historical'.'PK__VE_event_histori__00551192' in database 'ViewEvent' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files tothe filegroup, or setting autogrowth on for existing files in the filegroup.

Решение в данном случае простое - нужно выполнить операцию по очистке старых данных из БД SQL Server (Shrink Database). Делается это в SQL Management Studio - нужно выбрать базу данных и выполнить Tasks -> Shrink -> Database:

Смотрим, что получится и нажимаем Ok:

Также в KB 1025914 вы найдете более детальную информацию о том, как почистить базы данных Microsoft SQL Server и Oracle. Там же есть и скрипты очистки БД:

Завтра, 20 октября, компания Код Безопасности проведет бесплатный вебинар по продукту vGate R2, который предназначен для защиты виртуальной инфраструктуры VMware vSphere и Microsoft Hyper-V от несанкционированного доступа, а также для ее безопасной настройки средствами политик.

Тема вебинара - "Защита виртуальных инфраструктур: комбинация встроенных механизмов платформы виртуализации и сторонних средств". Мероприятие проведет Иван Колегов, системный аналитик компании «Код Безопасности». На вебинаре будет рассказано о защите виртуальных инфраструктур с помощью встроенных механизмов платформы виртуализации и сторонних средств.

Время и дата проведения: 20 октября в 11:00 по московскому времени.

Регистрируйтесь!

Мы часто пишем о проблемах вложенной виртуализации (nested virtualization), которая представляет собой способ запустить виртуальные машины на гипервизоре, который сам установлен в виртуальной машине. На платформе VMware ESXi эта проблема давно решена, и там nested virtualization работает уже давно, мало того - для виртуального ESXi есть даже свои VMware Tools.

Как мы недавно писали, решения для вложенной виртуализации на платформе Microsoft Hyper-V не было. При попытке запустить виртуальную машину на виртуальном хосте Hyper-V администраторы получали вот такую ошибку:

VM failed to start. Failed to start the virtual machine because one of the Hyper-V components is not running.

Все это происходило из-за того, что Microsoft не хотела предоставлять виртуальным машинам средства эмуляции техник аппаратной виртуализации Intel VT и AMD-V. Стандартная схема виртуализации Hyper-V выглядела так:

Virtualization Extensions передавались только гипервизору хостовой ОС, но не гостевой ОС виртуальной машины. А без этих расширений виртуальные машины в гостевой ОС запущены быть не могли.

В Windows 10 Build 10565 (этот превью-билд можно скачать по этой ссылке для x64 и по этой для x86) компания Microsoft, наконец-то, решила поменять ситуацию: теперь Virtualization Extensions передаются в гостевую ОС:

Соответственно, это позволит запустить вложенные виртуальные машины на хосте, который сам является виртуальной машиной с гостевой ОС Windows и включенной ролью Hyper-V.

На данный момент работает это только с Intel VT, но по идее к релизу Windows Server 2016 должно заработать и для AMD-V.

Сфера применения вложенных виртуальных машин не такая уж и узкая. Сейчас видится 2 основных направления:

• Виртуальные тестовые лаборатории, где развертываются виртуальные серверы Hyper-V и строятся модели работающих виртуальных инфраструктур в рамках одного физического компьютера.
• Использование контейнеризованных приложений (например, на движке Docker) в виртуальных машинах на виртуальных хостах Hyper-V. Более подробно о Windows Server Containers можно почитать вот тут. Немногим ранее мы писали об аналогичной архитектуре на базе VMware vSphere, анонсированной на VMware VMworld 2015.

Надо отметить, что для вложенных виртуальных машин не поддерживаются следующие операции (как минимум):

• Dynamic Memory
• Горячее изменение памяти работающей ВМ
• Снапшоты
• Live Migration
• Операции save/restore

Ну и вообще, вряд ли вложенная виртуализация вообще когда-нибудь будет полностью поддерживаться в производственной среде. Кстати, вложенная виртуализация на сторонних гипервизорах (например, VMware vSphere) также не поддерживается.

Для того, чтобы вложенная виртуализация заработала, нужно:

1. Использовать Windows 10 Build 10565. Windows Server 2016 Technical Preview 3 (TPv3) и Windows 10 GA - не подойдут, так как в них возможности Nested Virtualization нет.

2. Включить Mac Spoofing на сетевом адаптере виртуального хоста Hyper-V, так как виртуальный коммутатор хостового Hyper-V будет видеть несколько MAC-адресов с этого виртуального адаптера.

3. В Windows 10 нужно отключить фичу Virtualization Based Security (VBS), которая предотвращает трансляцию Virtualization Extensions в виртуальные машины.

4. Предусмотреть память под сам гостевой гипервизор и под все запущенные виртуальные машины. Память для гипервизора можно рассчитать так:

Теперь для того чтобы включить Nested Virtualization, выполните следующий сценарий PowerShell (в нем и VBS отключается, и Mac Spoofing включается):

Invoke-WebRequest https://raw.githubusercontent.com/Microsoft/Virtualization-Documentation/master/hyperv-tools/Nested/Enable-NestedVm.ps1 -OutFile ~/Enable-NestedVm.ps1

~/Enable-NestedVm.ps1 -VmName <VmName>

Далее создайте виртуальную машину на базе Windows 10 Build 10565, и включите в ней Mac Spoofing (если вы не сделали это в скрипте). Сделать это можно через настройки ВМ или следующей командой PowerShell:

Set-VMNetworkAdapter -VMName <VMName> -MacAddressSpoofing on

Ну а дальше просто запускайте виртуальную машину на виртуальном хосте Hyper-V:

После выхода новой версии платформы VMware vSphere 6 перед многими администраторами встал вопрос об обновлении различных компонентов виртуальной инфраструктуры. На крупных предприятиях, как правило, используется не только платформа VMware ESXi и сервисы управления vCenter, но и различные корпоративные продукты, такие как VMware Horizon View для инфраструктуры виртуальных ПК или VMware vRealize Operations (vROPs) для мониторинга и решения проблем.

Вот в какой правильной последовательности нужно обновлять решения VMware (если у нескольких продуктов очередь одна - их можно обновлять в любой последовательности):

О проведении операций по обновлению компонентов решений VMware более подробно рассказано в статье KB 2109760. Там же приведены примеры сценариев обновления, если у вас есть определенный набор продуктов.

Кстати, помните, что после обновления на VMware vSphere 6.0 вы не сможете использовать продукт VMware Storage Appliance, который больше не поддерживается.

Если вы хотите узнать совместимость различных продуктов для виртуальной инфраструктуры, воспользуйтесь ресурсом VMware Product Interoperability Matrixes.

Этой статьёй я хочу открыть серию статей, целью каждой из которых будет описание одной из написанных мной функций PowerCLI или так называемых командлетов (cmdlets), предназначенных для решения задач в виртуальных инфраструктурах, которые невозможно полноценно осуществить с помощью только лишь встроенных функций PowerCLI. Все эти функции будут объединены в один модуль - Vi-Module. Как им пользоваться, можете почитать здесь.

Мы часто рассказываем о решении vGate R2 от компании Код Безопасности, предназначенном для защиты виртуальной инфраструктуры VMware vSphere и Microsoft Hyper-V от несанкционированного доступа, а также для ее безопасной настройки средствами политик.

Не так давно мы писали о новых возможностях vGate 2.8, а ниже расскажем о реальном использовании продукта в производственной среде организации, работающей с чувствительными данными.

Компания «Код Безопасности», российский разработчик программных и аппаратных средств защиты, сообщает о реализации проекта по внедрению средства защиты vGate в центре обработки данных (ЦОД) «Электронного правительства» Ленинградской области.

Заказчиком проекта выступил Комитет по телекоммуникациям и информатизации Ленинградской области; работы по внедрению продукта осуществлялись при участии специалистов ГКУ ЛО «Оператор электронного правительства». Поставка средства защиты информации vGate была реализована партнером «Кода Безопасности» в Северо-Западном федеральном округе – Группой компаний SuperWave.

Центр обработки данных правительства Ленинградской области представляет собой виртуализированный кластер, построенный на современной платформе VMware vSphere. В ЦОДе функционируют различные информационные системы исполнительных органов государственной власти Ленобласти, в том числе портал государственных и муниципальных услуг, система обеспечения деятельности региональных МФЦ, бухгалтерские и учетные системы, системы ЭДО, базы данных CRM-систем и пр. В этих государственных информационных системах хранятся и обрабатываются персональные данные и другая конфиденциальная информация. vGate R2 обеспечивает сертифицированную защиту этой информации и позволяет привести виртуальную инфраструктуру в соответствие требованиям приказов ФСТЭК России № 17 и № 21 и подготовить систему к прохождению аттестации.

«Перед началом проекта был сформирован список основных требований к системе защиты ЦОДа правительства Ленинградской области. Мы искали решение, которое сертифицировано по требованиям ФСТЭК России, поддерживает работу с платформой VMware, реализует защиту исключительно программными средствами, имеет развитый функционал и различные механизмы обеспечения безопасности в виртуальной инфраструктуре. vGate оказался единственным решением, удовлетворяющим всем нашим требованиям» – рассказал директор ГКУ ЛО «ОЭП», Кораблев Михаил Анатольевич.

Более подробно узнать о продукте vGate R2 и скачать его актуальную версию можно по этой ссылке.

Как вы знаете, некоторое время назад компания VMware выпустила обновление платформы виртуализации vSphere 6 Update 1. После его выхода компания Veeam предупредила пользователей, что средство резервного копирования виртуальных машин Veeam Backup & Replication 8.0 пока не поддерживает последнее обновление от VMware. И вот на днях вышел Veeam Backup & Replication 8.0 Update 3 с полной поддержкой vSphere 6 Update 1. Так что большинство пользователей платформы ESXi может смело обновлять свою инфраструктуру.

Посмотрим на все новые возможности последнего обновления Veeam B&R:

Улучшения для Microsoft Windows:

• Поддержка Windows 10 в качестве гостевой ОС (включая обработку приложений - application-aware processing).
• Поддержка установки Veeam Backup & Replication и всех его компонентов на Windows 10.

Улучшения для VMware vSphere:

• Поддержка vSphere 6.0 Update 1.
• Возможность превратить предупреждение "VMware Tools not found" в информационное сообщение. Для этого параметр DisableVMwareToolsNotFoundWarning (REG_DWORD) в реестре нужно установить в значение 1.

Улучшения для Linux:

• Поддержка SSH-шифрования: aes128-ctr, aes192-ctr, aes256-ctr, aes192-cbc и aes256-cbc.

Новое у Veeam Explorer for Microsoft SQL Server:

• Лог транзакций для неподдерживаемых экземпляров SQL Server автоматически игнорируется, чтобы избежать сообщений об ошибке.
• Предпочитаемые сетевые настройки также применяются к задачам бэкапа транзакционного лога.

Новое у Veeam Explorer for SharePoint:

• Поддержка аутентификации ADFS
• Поддержка UPN credentials.

Улучшения SureBackup

• Модуль Proxy appliance теперь отвечает на пинг внутри виртуальной лаборатории (Virtual Lab), чтобы сетевые экраны не блокировали автоматически ее сеть как публичную.

Другое:

• Улучшено шифрование.
• Улучшена производительность операций консоли в больших окружениях.
• Уменьшена нагрузка на сервер SQL, а также увеличена надежность.
• Увеличена производительность настройки конфигурации резервного копирования для больших окружений.
• Прочие исправления ошибок в различных областях.

Скачать Veeam Backup & Replication 8.0 Update 3 можно по этой ссылке (нужно залогиниться).

В конце прошлой недели компания Citrix выпустила обновления для своих флагманских продуктов - Feature Pack 3 for XenApp and XenDesktop 7.6. Напомним, что о новых возможностях новых версий этих решений мы писали вот тут.

О возможностях второго фиче-пака можно прочитать вот тут, а про первый написано здесь. Кроме того, на эту тему есть специальный FAQ.

Новые возможности Feature Pack 3 for XenApp and XenDesktop 7.6:

• Новый Windows Workstation Virtual Delivery Agent (VDA), который упрощает развертывание новых ПК (в том числе, на базе Windows 10), а также их миграцию на Windows 10.
• Citrix Receiver for Windows 10 - новая версия ПО для доступа к опубликованным приложениям XenApp/XenDesktop.
• Новая версия Citrix AppDNA 7.6.5 - средства, упрощающего миграцию на Windows 10 путем виртуализации физически установленных у пользователей приложений.
• Существенные улучшения производительности, в том числе технологии Thinwire, отвечающей за отображение пользовательского окружения на тонких клиентах.
• Улучшенные шаблоны HDX Policy Templates, касающиеся настроек доставки пользователям интерфейса приложений и десктопов. Также доступны новые наборы преконфигурированных шаблонов.
• Улучшения Universal Print Server, который теперь доступен и для Windows Server 2012 R2, а также поддержка клиентов Windows 10.
• Аутентификация по смарт-картам стала работать на 25% быстрее.
• Появилась политика Restrict Access from Jailbroken Devices, позволяющая предотвращать доступ с джейлбрейкнутых устройств.
• Технология HDX MediaStream может проверять соответствие версий Flash на клиенте и сервере во избежание проблем совместимости.
• Улучшенная поддержка планшетов для рисования (Wacom), включая средства для цифровой подписи контента с помощью смарт-карт.

Также вы можете посетить вебинар What’s New in Feature Pack 3, который пройдет 14 октября.

Мы уже писали о новой версии решения VMware Virtual SAN 6.1, предназначенной для создания отказоустойчивых хранилищ на платформе VMware vSphere. После того, как издания "hybrid" и "all-flash" были переименованы в "standard" и "advanced" соответственно, у пользователей появилось несколько вопросов о функциональности этих изданий.

Начнем с того, что в целом все осталось как было:

Итак, мы видим, что отличий у изданий Standard и Advanced теперь два:

• Для конфигураций только из SSD-дисков серверов можно использовать только издание Advanced.
• Для "растянутых" кластеров также можно использовать только издание Advanced. Но тут есть нюанс - растянутым кластером можно считать географически разнесенные площадки (на уровне двух разных зданий). Если у вас кластер на уровне стоек в двух серверных или на разных этажах - растянутым он не считается.

Также появилось издание VSAN for ROBO (remote or branch offices). Это издание позволяет использовать решение VSAN компаниям имеющую сеть небольших филиалов, где нет большого числа хостов ESXi. Для такой лицензии можно запустить не более 25 виртуальных машин в рамках филиала и одной ROBO-лицензии.

Здесь кластеры строятся на уровне каждого из филиалов, а witness-компонент (виртуальный модуль, следящий за состоянием кластера) располагается в инфраструктуре центрального офиса. Причем на каждый кластер VSAN нужно по отдельному witness'у. Этот самый witness позволяет построить кластер на базе всего двух узлов, а не трех, так как он следит за ситуацией split brain в кластере. Это позволяет удешевить решение для филиала, использовав для инфраструктуры из 25 машин всего 2 сервера. Более подробно о ROBO-сценарии написано вот тут.

А вот как выглядит настройка ROBO-издания Virtual SAN:

Ну и, само собой, ROBO-сценарии можно реализовывать по своему усмотрению на лицензиях Standard или Advanced.

Мы уже немало писали про технологию использования хранилищ VVols (например, здесь и здесь), которая позволяет существенно увеличить производительность операций по работе с хранилищами в среде VMware vSphere за счет использования отдельных логических томов под компоненты виртуальных машин и передачи части операций по работе с ними на сторону дисковых массивов.

Давайте посмотрим, как же технология VVols влияет на процесс резервного копирования виртуальных машин, например, с помощью основного продукта для бэкапа ВМ Veeam Backup and Replication, который полностью поддерживает VVols. Для начала рассмотрим основные способы резервного копирования, которые есть в виртуальной среде:

• Резервное копирование за счет монтирования виртуальных дисков (Hot Add backup) - в этом случае к одной ВМ монтируется диск VMDK другой ВМ и происходит его резервное копирование
• Резервное копирование по сети передачи данных (NBD backup) - это обычное резервное копирование ВМ по сети Ethernet, когда снимается снапшот ВМ (команды отдаются хостом ESXi), основной диск передается на бэкап таргет, а потом снапшот применяется к основному диску ("склеивается" с ним) и машина продолжает работать как раньше.
• Резервное копирование по сети SAN (SAN-to-SAN backup) - в этом случае на выделенном сервере (Backup Server) через специальный механизм Virtual Disk API происходит снятие снапшота ВМ без задействования хоста ESXi и бэкап машины на целевое хранилище напрямую в сети SAN без задействования среды Ethernet.

Последний способ - самый быстрый и эффективный, но он требует наличия специальных интерфейсов (vSphere APIs и Virtual Disk Development Kit, VDDK), которые должны присутствовать на выделенном сервере.

К сожалению, для VVols способ резервного копирования по сети SAN еще не поддерживается, так как данный механизм для прямой работы с хранилищами SAN для VVols еще не разработан. Поэтому при работе с VVols придется использовать NBD backup. Однако не расстраивайтесь - большинство компаний именно его и используют для резервного копирования машин на томах VMFS в силу различных причин.

Работа хоста VMware ESXi с томами виртуальной машины VVols выглядит следующим образом:

Для процессинга операций используется Protocol Endpoint (PE), который представляет собой специальный административный LUN на хранилище. PE работает с лунами машин (VVols), которые представлены через secondary LUN ID, а VASA Provider со стороны дискового массива снабжает vCenter информацией о саблунах виртуальных машин, чтобы хост ESXi мог с ними работать через PE.

Таким образом, в новой архитектуре VVols пока не прикрутили технологический процесс соединения стороннего сервера с VVols виртуальных машин и снятия с них резервных копий.

Вернемся к процессу резервного копирования. Как известно, он опирается на механизм работы снапшотов (Snapshots) - перед снятием резервной копии у ВМ делается снапшот, который позволяет перевести базовый диск в Read Only, а изменения писать в дельта-диск снапшота. Далее базовый диск ВМ копируется бэкап-сервером, ну а после того, как базовый диск скопирован, снапшот склеивается с основным диском, возвращая диски машины обратно в консолидированное состояние.

Так это работает для файловой системы VMFS, которая развертывается поверх LUN дискового массива. Сами понимаете, что при интенсивной нагрузке во время резервного копирования (особенно больших виртуальных дисков) с момента снятия снапшота может пройти довольно много времени. Поэтому в дельта-дисках может накопиться много данных, и процесс консолидации снапшота на практике иногда занимает часы!

Для виртуальных томов VVols все работает несколько иначе. Давайте взглянем на видео:

В среде VVols при снятии снапшота базовый диск остается режиме Read/Write (это все делает массив), то есть контекст записи данных никуда не переключается, и изменения пишутся в базовый диск. В снапшоты (это отдельные тома VVol) пишется только информация об изменениях базового диска (какие дисковые блоки были изменены с момента снятия снапшота).

Ну а при удалении снапшота по окончанию резервного копирования никакой консолидации с базовым диском производить не требуется - так как мы продолжаем с ним работать, просто отбрасывая дельта-диски.

Такой рабочий процесс несколько увеличивает время создания снапшота в среде VVols:

Но это всего лишь десятки секунд разницы. А вот время консолидации снапшота по окончанию резервного копирования уменьшается во много раз:

Как следствие, мы имеем уменьшение совокупного времени резервного копирования до 30%:

Так что, если говорить с точки зрения резервного копирования виртуальных машин, переход на VVols обязательно даст вам прирост производительности операций резервного копирования и позволит уменьшить ваше окно РК.

Недавно мы писали том, что компания Код Безопасности, производитель решений номер 1 для защиты виртуальных сред, выпустила обновление продукта vGate R2 версии 2.8. Эта версия прошла инспекционный контроль в ФСТЭК России и доступна для загрузки и покупки. В обновленную версию vGate R2 добавлены новые механизмы защиты и расширенные функции по администрированию системы. Сегодня мы расскажем о том, как в vGate R2 выглядит рабочий процесс для пользователей в защищенной среде.

Интересный пост, касающийся поддержки VMware Tools в смешнном окружении, опубликовали на блогах VMware. Если вы взглянете на папку productLocker в ESXi, то увидите там 2 подпапки /vmtools и /floppies:

Это файлы, относящиеся к пакету VMware Tools, устанавливаемому в гостевые ОС виртуальных машин. Перейдем в папку /vmtools:

Тут находится куча ISO-образов с данными пакета (каждый под нужную гостевую ОС), файл манифеста, описывающий имена, версии и ресурсы файлов пакета, а также сигнатура ISO-шки с тулзами, позволяющая убедиться, что она не была изменена.

В папке floppies находятся виртуальные образы дискет, которые могут понадобиться для специфических гостевых ОС при установке драйверов (например, драйвер устройства Paravirtual SCSI):

Интересно, что папка productLocker занимает примерно 150 МБ, что составляет где-то половину от размера установки VMware ESXi. Именно поэтому рекомендуют использовать образ ESXi без VMware Tools ("no-tools") при использовании механизма Auto Deploy для массового развертывания хост-серверов.

Самая соль в том, что версия пакета VMware Tools на каждом хосте разная и зависит от версии VMware ESXi. Например, мы поставили на хосте VMware vSphere 5.5 виртуальную машину и установили в ней тулзы. Консоль vCenter покажет нам, что установлена последняя версия VMware Tools:

Однако если у нас смешанная инфраструктура (то есть, состоит их хостов разных версий), то при перемещении машины на хост с более высокой версией, например, vSphere 5.5 Update 2/3, она будет показана как ВМ с устаревшей версией пакета (VMware Tools: Running (Out-of-Date):

Поэтому возникает некоторая проблема в смешанной среде, которую можно решить очень просто - как правило VMware Tools от хоста с большей версией подходят ко всем предыдущим. Например, тулзы от vSphere 6.0 подойдут ко всем хостам до ESXi 4.0 включительно. vSphere 6 Update 1 выпадает из списка (постепенно поддержка старых версий уходит):

Таким образом, лучше всего распространить тулзы от vSphere 6 на все хосты вашей виртуальной инфраструктуры. Для этого создадим общий для всех хостов датастор SDT и через PowerCLI проверим, что к нему имеет доступ несколько хостов, командой:

Get-Datastore | where {$_.ExtensionData.summary.MultipleHostAccess -eq “true”}

Далее создадим на этом датасторе папку productLocker:

в которую положим VMware Tools от ESXi 6.0:

Далее нужно пойти в раздел:

Manage > Settings > Advanced System Settings > UserVars.ProductLockerLocation

и вбить туда путь к общей папке, в нашем случае такой:

/vmfs/volumes/SDT/productLocker

Если вы хотите применить эту настройку сразу же на всех хостах кластера, то можно использовать следующий командлет PowerCLI:

Get-VMhost -Location <cluster name> | Set-VMHostAdvancedConfiguration -Name "UserVars.ProductLockerLocation" -Value "/vmfs/volumes/SDT/productLocker"

Теперь для применения настроек есть два пути: первый - это перезапустить хост ESXi, но если вы этого сделать не можете, то есть и второй путь - выполнить несколько команд по SSH.

Зайдем на хост ESXi через PuTTY и перейдем в папку с /productLocker командой cd. Вы увидите путь к локальной папке с тулзами на хосте, так как это ярлык:

Удалим этот ярлык:

rm /productLocker

После чего создадим новый ярлык на общую папку на томе VMFS с тулзами от vSphere 6.0:

ln -s /vmfs/volumes/SDT/productLocker /productLocker

Посмотрим, что все смонтировалось, командой ls:

Вот таким вот образом можно поддерживать самую последнюю версию VMware Tools в виртуальных машинах, когда в вашей производственной среде используются различные версии VMware ESXi.

Недавно Cormac Hogan написал интересный пост о том, как нужно настраивать "растянутый" между двумя площадками HA-кластер на платформе VMware vSphere, которая использует отказоустойчивую архитектуру Virtual SAN.

Напомним, как это должно выглядеть (два сайта на разнесенных площадках и witness-хост, который обрабатывает ситуации разделения площадок):

Основная идея такой конфигурации в том, что при отказе отдельного хоста или его компонентов виртуальная машина обязательно должна запуститься на той же площадке, где и была до этого, а в случае отказа всей площадки (аварии) - машины должны быть автоматически запущены на резервном сайте.

Откроем настройки кластера HA. Во-первых, он должен быть включен (Turn on vSphere HA), и средства обнаружения сетевых отказов кластера (Host Monitoring) также должны быть включены:

Host Monitoring позволяет хостам кластера обмениваться сигналами доступности (heartbeats) и в случае отказа предпринимать определенные действия с виртуальными машинами отказавшего хоста.

Для того, чтобы виртуальная машина всегда находилась на своей площадке в случае отказа хоста (и использовала локальные копии данных на виртуальных дисках VMDK), нужно создать Affinity Rules, которые определяют правила перезапуска ВМ на определенных группах хостов в рамках соответствующей площадки. При этом эти правила должны быть "Soft" (так называемые should rules), то есть они будут соблюдаться при возможности, но при отказе всей площадки они будут нарушены, чтобы запустить машины на резервном сайте.

Далее переходим к настройке "Host Hardware Monitoring - VM Component Protection":

На данный момент кластер VSAN не поддерживает VMCP (VM Component Protection), поэтому данную настройку надо оставить выключенной. Напомним, что VMCP - это новая функция VMware vSphere 6.0, которая позволяет восстанавливать виртуальные машины на хранилищах, которые попали в состояние All Paths Down (APD) или Permanent Device Loss (PDL). Соответственно, все что касается APD и PDL будет выставлено в Disabled:

Теперь посмотрим на картинку выше - следующей опцией идет Virtual Machine Monitoring - механизм, перезапускающий виртуальную машину в случае отсутствия сигналов от VMware Tools. Ее можно использовать или нет по вашему усмотрению - оба варианта полностью поддерживаются.

На этой же кариинке мы видим настройки Host Isolation и Responce for Host Isolation - это действие, которое будет предпринято в случае, если хост обнаруживает себя изолированным от основной сети управления. Тут VMware однозначно рекомендует выставить действие "Power off and restart VMs", чтобы в случае отделения хоста от основной сети он самостоятельно погасил виртуальные машины, а мастер-хост кластера HA дал команду на ее восстановление на одном из полноценных хостов.

Далее идут настройки Admission Control:

Здесь VMware настоятельно рекомендует использовать Admission Control по простой причине - для растянутых кластеров характерно требование самого высокого уровня доступности (для этого он, как правило, и создается), поэтому логично гарантировать ресурсы для запуска виртуальных машин в случае отказа всей площадки. То есть правильно было бы зарезервировать 50% ресурсов по памяти и процессору. Но можно и не гарантировать прям все 100% ресурсов в случае сбоя, поэтому можно здесь поставить 30-50%, в зависимости от требований и условий работы ваших рабочих нагрузок в виртуальных машинах.

Далее идет настройка Datastore for Heartbeating:

Тут все просто - кластер Virtual SAN не поддерживает использование Datastore for Heartbeating, но такого варианта тут нет :) Поэтому надо выставить вариант "Use datastores only from the secified list" и ничего из списка не выбирать (убедиться, что ничего не выбрано). В этом случае вы получите сообщение "number of vSphere HA heartbeat datastore for this host is 0, which is less than required:2".

Убрать его можно по инструкции в KB 2004739, установив расширенную настройку кластера das.ignoreInsufficientHbDatastore = true.

Далее нужно обязательно установить кое-какие Advanced Options. Так как кластер у нас растянутый, то для обнаружения наступления события изоляции нужно использовать как минимум 2 адреса - по одному на каждой площадке, поэтому расширенная настройка das.usedefaultisolationaddress должна быть установлена в значение false. Ну и нужно добавить IP-адреса хостов, которые будут пинговаться на наступление изоляции хост-серверов VMware ESXi - это настройки das.isolationaddress0 и das.isolationaddress1.

Таким образом мы получаем следующие рекомендуемые настройки растянутого кластера HA совместно с кластером Virtual SAN:

Ну и должны быть добавлены следующие Advanced Settings:

Более подробно об этом всем написано в документе "Virtual SAN 6.1 Stretched Cluster Guide".

Не так давно мы писали о гиперконвергентной платформе StarWind Hyper-Converged Platform (H-CP), которая позволяет построить полноценную ИТ-инфраструктуру небольшого предприятия на базе продуктов компаний StarWind, Veeam, VMware и Microsoft. H-CP поставляется в виде уже готовых к использованию серверов с предустановленными компонентами от соответствующих вендоров.

Теперь у StarWind появилась специальная страница, посвященная Hyper-Converged Platform. Ну и, кроме этого, об H-CP можно узнать из вот этого видео:

Строится все это на базе следующих аппаратных платформ:

Подробно об аппаратных характеристиках платформы H-CP от StarWind можно узнать из этого документа.

15 октября в 15:00 ИТ-ГРАД проводит презентацию новых высокопроизводительных флеш-массивов AFF от NetApp. На мероприятии вы узнаете о новой расширенной линейке флеш-массивов СХД, разработанной для корпоративных клиентов. Спикерами мероприятия выступят инженеры NetApp и ИТ-ГРАД.

ИТ-ГРАД приглашает вас посетить мероприятие-презентацию новых флеш-массивов All Flash FAS (AFF) 8000 от NetApp. Серия AFF на NetApp Data ONTAP призвана повысить производительность и эффективность флеш-данных.

Узнать подробнее о новинках можно от первых лиц компании NetApp, которые выступят спикерами мероприятия.

Участие в мероприятие бесплатное. Регистрируйтесь и присоединяйтесь!

Компания VMware на днях сделала доступными видеозаписи основных докладов с прошедшей недавно конференции VMware VMworld 2015, где было сделано множество интересных анонсов.

• General Session – Monday, August 31, 2015 (Carl Eschenbach, VMware – Bill Fathers, VMware – Raghu Raghuram – VMware, Ray O’Farrell, VMware)

• General Session – Tuesday, September 1, 2015 (Sanjay Poonen, VMware – Martin Casado, VMware – Pat Gelsinger, VMware)

Остальные видео - внутри поста.

Компания VMware выпустила обновление для прошлой версии платформы виртуализации - vSphere 5.5 Update 3. Не секрет, что большое количество компаний еще использует версию 5.5, так как на больших предприятиях процесс апгрейда ПО и лицензий протекает очень медленно. Поэтому данное обновление им будет весьма кстати.

Что нового в VMware vSphere 5.5 Update 3:

• Управление механизмом ротации логов - теперь можно задавать ограничение по размеру лог-файлов в vmx (для каждого лога) и количество хранимых логов.
• Сертификация адаптера PVSCSI – теперь устройство виртуальных дисков PVSCSI можно использовать для кластеров MSCS, а также кластеризации приложений, таких как Microsoft SQL или Exchange. Это позволит существенно повысить производительность по сравнению с адаптерами LSI Logic SAS.
• Поддержка новых процессоров серверов - теперь платформа поддерживает последние поколения процессоров от Intel и AMD. Подробнее об этом написано в VMware Compatibility Guide.
• Аутентификация серверов ESXi в Active Directory – ESXi поддерживает шифрование AES256-CTS/AES128-CTS/RC4-HMAC для коммуникации Kerberos между ESXi и Active Directory.
• Поддержка новых баз данных - теперь vCenter Server поддерживает следующие СУБД:
  • Oracle 12c R1 P2 (12.1.0.2)
  • Microsoft SQL Server 2012 Service Pack 2
  • Microsoft SQL Server 2008 R2 Service Pack 3
• Поддержка новых операционных систем - новые гостевые ОС теперь полностью поддерживаются:
  • CentOS 7.0
  • Oracle Linux 7.0
  • Ubuntu 14.10
  • Windows 10
  • RHEL 6.6
  • RHEL 7 .1
  • CentOS 7.1
  • Oracle Linux 7.1
• File Transfer Log – теперь в лог-файлы пишется информация о файлах, переданных на хост ESXi или загруженных с него через vSphere Web Client или vSphere Client.

Также были обновлены несколько сопутствующих продуктов для виртуальной инфраструктуры. Вот ссылки:

• VMware vCenter Server 5.5 Update 3 [Release Notes] [Скачать]
• VMware ESXi 5.5.0 Update 3 [Release Notes] [Скачать]
• VMware vCenter Orchestrator Appliance 5.5.3 [Release Notes] [Скачать]
• VMware vCenter Site Recovery Manager 5.8.1 [Release Notes] [Скачать]
• VMware vSphere Replication 5.8.1 [Release Notes] [Скачать]
• vRealize Operations Management Pack for MEDITECH 1.0.0 [Release Notes] [Скачать]

Напомним, что в каждом из документов Release Notes есть раздел What's New, где можно узнать о новых возможностях соответствующего продукта.

Мы уже не раз писали о возможностях средства VMware vRealize Log Insight (например, тут и тут) для автоматизированного управления файлами журналов, а также сбора различных данных, их анализа и поиска. На прошедшей недавно конференции VMworld 2015 компания VMware анонсировала мажорный релиз этого средства - Log Insight 3.0.

Давайте взглянем на новые возможности продукта:

1. Возможности Log Insight 3 для больших инсталляций.

Не секрет, что продукт Log Insight ориентирован на большие инфраструктуры, где требуется централизованно обрабатывать и осуществлять поиск по сотням, а иногда и даже десяткам тысяч логов. Теперь решение обрабатывает в два раза больший объем данных в секунду (до 15 тысяч событий) на один узел. Максимальное число узлов кластера vRealize Log Insight также возросло - теперь 12 узлов могут обрабатывать 2,7 ТБ данных в день!

2. Улучшения движка аналитики.

К ним можно отнести:

• Многофункциональные диаграммы - на одном графике можно выводить функции MIN, MAX и AVG для различных сущностей.
• Интерактивные снапшоты аналитики - теперь можно визуализовать историю просмотра логов и использовать функцию "снапшота" запросов. Вы можете сравнить два разных запроса в снапшотах или использовать их для создания новых дэшбордов.
• URL Shortener - обрезалка урлов, чтобы можно было удобно посылать ссылки на интерактивную аналитику коллегам.
• События группируются по типам (объединяются одним цветом), что позволяет быстрее распознать характер события.
• Тренды событий - теперь можно устанавливать кастомный диапазон времени и бэйслайны для них.

3. Улучшенные функции администрирования.

Здесь появились следующие нововведения:

• Подхватывание роли мастер-узла другим узлом в случае временной или постоянной недоступности первого.
• Возможность обновления без простоя одной кнопкой - при апгрейде узла он выводится из кластера, после чего обновляется на новую версию (при этом балансировщик в данной архитектуре не нужен).
• Возможность форвардинга событий по UDP - теперь события syslog могут пересылаться не только по TCP.
• Архивирование данных напрямую на Hadoop Distributed Filesystem (HDFS).

4. Легкий агент сбора данных для различных систем.

Здесь имеется в виду вот что:

• Возможность массовой конфигурации агентов путем применения настроек на группу (из GUI).
• Использование парсеров на стороне клиента (с возможностью задания паттернов распознавания логов в зависимости от настроек и локали).
• Теперь события syslog посылаются по защищенному каналу SSL.

5. Улучшения документации.

• Документ по резервному копированию и восстановлению конфигураций можно посмотреть вот тут.
• vRealize Log Insight 3.0 GA Configuration Limits доступны по этой ссылке.

Скачать VMware vRealize Log Insight 3.0 можно по этой ссылке.

Совсем недавно компания VMware выпустила интересный документ о производительности операций виртуальной инфраструктуры под управлением VMware vCenter 6 для серверов, работающих в кластере HA/DRS - "VMware vCenter Server 6.0 Cluster Performance".

Упор сделан на сравнение производительности свежей версии vCenter 6.0 с предшественником - vCenter 5.5. Напомним, что шестая версия поддерживает до 64 хоста ESXi в кластере и до 8000 виртуальных машин (до этого было 32 хоста ESXi и 3000 виртуальных машин).

Конфигурация тестовой среды была следующей:

Программные компоненты:

Производительность каких операций проверялась:

• Add Port Group
• Remove Port Group
• Clone VM
• Create Folder
• Delete Folder
• Create Snapshot
• Delete Snapshot
• Group Power-On VMs
• vMotion VM
• Power On VM
• Power Off VM
• Reconfigure VM
• Register VM
• Unregister VM
• Relocate VM
• Remove VM
• Reset VM
• Suspend VM
• Resume VM

В результате тестирования были получены следующие результаты:

• vCenter 6.0 показывает лучшую операционную производительность (в количестве операций) до 66% лучше прошлой версии.

• Улучшенная производительность под очень тяжелыми нагрузками.
• Одинаковая производительность как vCenter Server для Windows, так и виртуального модуля vCSA на базе Linux.
• Операции с виртуальными машинами происходят существенно быстрее.

Больше интересных подробностей и графиков вы можете найти в документе.

Многие из вас в курсе, что решение StarWind Virtual SAN обеспечивает лучшую в отрасли защиту виртуальных машин на платформе Microsoft Hyper-V за счет создания стабильно работающего отказоустойчивого кластера хранилищ.

Для тех, кто еще не развертывал этот продукт, компания StarWind подготовила видеоруководство "StarWind Virtual SAN Free: Virtualized Shared Storage for Microsoft Hyper-V. Step-by-step", в рамках которого вы сможете посмотреть, как меньше чем за час развернуть отказоустойчивый кластер хранилищ для виртуальных машин Microsoft Hyper-V (для просмотра видео потребуется заполнить форму):

Ну а для тех, кто видео смотреть не любит, есть простой и понятный документ "StarWind Virtual SAN Free Getting Started", где вся процедура описывается просто и наглядно на нескольких страницах.

На проходящей сейчас конференции VMworld 2015 компания VMware представила новую версию своего решения для виртуализации рабочих мест предприятия VMware Horizon 6.2. Основные нововведения коснулись продукта VMware Horizon View 6.2, отвечающего за виртуализацию ПК и создание VDI-инфраструктуры компании. Напомним, что о новых возможностях решения VMware Horizon View 6.1 мы писали вот тут.

Давайте посмотрим, что нового появилось в VMware Horizon View 6.2:

1. Поддержка архитектуры Cloud Pod для опубликованных приложений (RDS).

Ранее эти функции были доступны только для виртуальных десктопов, теперь же масштабируемая архитектура облачных блоков доступна и для сервисов RDS. Теперь пространство управления доступом пользователей распространяется на уровне датацентра и между датацентрами, включая сильно географически разделенные площадки.

2. Функции HTML Access for Cloud Pod

Теперь на глобальном уровне можно получить доступ к виртуальному ПК одного из подов прямо по ссылке из браузера с поддержкой HTML 5. Для доступа используется протокол Blast.

3. Стали доступны средства балансировки нагрузки RDSH и интеллектуального размещения сессий.

Теперь для определения загрузки хостов и приложений используются счетчики perfmon, а сессии пользователей балансируются между серверами RDSH на основе этих данных. Безусловно, в Horizon View эти функции еще не такие мощные, как в Cirtix XenApp, но видно, что VMware развивается в этом же направлении.

4. Технология Linked Clones для виртуальных машин с сервисами RDS.

Теперь можно использовать View Composer для создания инфраструктуры связанных клонов (Linked Clones) для ферм RDSH. Это позволяет автоматизировать развертывание этих ферм на хост-серверах VMware ESXi, а также централизованно управлять ими, а самое главное - обновлять на уровне мастер-образа.

Эти функции для сервисов RDS пользователи ждали довольно давно.

5. Технология организации доступа Access Point.

Теперь нет необходимости размещать Windows-машину в DMZ, чтобы организовать безопасный доступ пользователей к их виртуальным ПК. В новой версии используется специализированный защищенный модуль на базе виртуального модуля (Virtual Appliance) Linux SLES 11, который можно выставить в DMZ (установка ПО весьма проста).

6. Поддержка однонаправленных трастов.

Теперь наличие двунаправленного траста не обязательно. Это востребовано в крупных инфраструктурах.

7. Поддержка новой версии технологии NVIDIA GRID 2.0.

Более подробно об этом можно прочитать вот тут. Теперь поддерживается новое поколение карт с процессорами Maxwell. Напомним, что ранее это были карточки NVIDIA K1/K2 (архитектура Keppler).

Новые графические карты M60/6 обещают быть в 2 раза более производительными и позволяют разместить до 128 пользователей, требовательных к производительности графической подсистемы, на одном сервере.

Более подробно об этом написано вот тут.

8. Поддержка AMD GPU для режима vDGA.

Мы уже писали, что такое режим vDGA, и почему он производительнее vSGA. Теперь режим vDGA Passthrough полностью поддерживается для карточек AMD. Кстати, эти карточки стоят дешевле, чем у NVIDIA, поэтому можно снизить стоимость такой инфраструктуры в определенных сценариях.

9. Поддержка функции 3D-ускорения для приложений RDS.

Теперь публикуемые через RDSH приложения тоже поддерживают режим аппаратного ускорения vDGA и vGPU (пока только для NVIDIA). Это может оказаться очень полезным и выгодным, в том числе по сравнению с виртуальными ПК.

10. Поддержка vGPU для Linux-десктопов.

Теперь не только Windows-пользователи смогут полноценно использовать функции vGPU от NVIDIA.

11. Перенаправление клиентского диска для VDI и RDSH.

Если раньше это перенаправление работало только для Windows, то теперь можно перенаправить диски Win и Mac клиентов, а также в экспериментальном режиме и для Linux.

12. Поддержка ассоциаций типов файлов для RDSH.

Теперь можно просто открыть файл с помощью опубликованного приложения по клику на него, а не искать из предварительно открытого приложения нужный файл.

13. Поддержка разрешения 4К.

Теперь мониторы с мегаразрешениями (3840x2160) полностью поддерживаются для инфраструктуры виртуальных ПК:

14. Поддержка Windows 10.

Теперь виртуальные ПК поддерживают в качестве гостевой ОС Windows 10, а также последние функции Skype.

Доступность VMware Horizon View 6.2 ожидается в ближайшее время.

Для вас мы четвертый год устраиваем VMware Tour и, что важно, проводим его с доставкой в ваш город. Мы будем очень рады встрече с вами в рамках этого традиционного роуд-шоу и уверены, что вы почерпнете много полезной информации, сможете пообщаться с коллегами, представителями вендоров и ведущих интеграторов — одним словом, проведете время с пользой!

На проходящей сейчас конференции VMworld 2015 было сделано множество интересных анонсов (впрочем, как и всегда). Конечно же, мы расскажем о всех тех, что достойны внимания. Одна из самых интересных новостей - это анонс новой версии решения для создания кластеров хранилищ VMware Virtual SAN 6.1.

Давайте взглянем на новые возможности этого решения:

1. Virtual SAN Stretched Cluster.

Теперь VSAN будет позволять создавать географически "растянутый" кластер хранилищ между датацентрами, продолжая обеспечивать функции отказоустойчивости. Репликация данных при этом работает с синхронном режиме.

2. Virtual SAN for Remote Office / Branch Office (ROBO)

В VSAN теперь появилась возможность развертывать множество двухузловых кластеров хранилищ, которыми можно централизованно управлять из одной консоли отдельного VMware vCenter Server, предназначенного для этой задачи. Этот сценарий подходит для компаний с большим числом небольших филиалов:

3. Virtual SAN Replication with vSphere Replication

Virtual SAN 6.1 теперь может использовать технологию vSphere Replication для асинхронной репликации данных на любые расстояния в комбинации с VMware Site Recovery Manager (SRM), чтобы получилось полностью законченное решения для восстановления инфраструктуры после сбоев.

Например, можно создать синхронно реплицируемый растянутый кластер хранилищ на расстояниях с latency менее 5 мс, а средствами vSphere Replication откидывать данные в географически удаленный датацентр:

4. Поддержка Multi-Processor Fault Tolerance (SMP-FT).

Теперь виртуальные машины, защищенные технологией FT, полностью поддерживаются со стороны VMware Virtual SAN 6.1, то есть кластер непрерывной доступности из виртуальных машин теперь защищен как со стороны вычислительных ресурсов, так и со стороны хранилищ.

5. Поддержка Windows Server Failover Clustering (WSFC) and Oracle Real Application Cluster (RAC).

В новой версии VSAN теперь поддерживаются технологии кластеризации от Oracle и Microsoft. Для Oracle RAC можно запускать несколько экземпляров Oracle RDBMS на одном хранилище. Точно так же можно использовать и кластеры Microsoft WSFC поверх хранилищ Virtual SAN:

6. Максимальная производительность и высокая скорость отклика.

Здесь было сделано 2 серьезных улучшения:

• Поддержка ULLtraDIMM SSD хранилищ, которые втыкаются в канал оперативной памяти (слоты DIMM), работающие с очень быстрым откликом на запись (менее 5 микросекунд). Это позволяет сделать хост All Flash с емкостью на 12 ТБ в форм-факторе блейд-сервера с троекратно большей производительностью, чем у внешних массивов.
• NVMe – интерфейс Non-Volatile Memory Express (NVMe), который был специально разработан для SSD, чтобы максимально распараллеливать операции на программном и аппаратном уровне. В тестах VMware, использующих эту технологию, было получено 3,2 миллиона IOPS на 32-узловом кластере при примерно 100 тысячах операций в секунду на одном хост-сервере ESXi.

7. Virtual SAN Health Check Plug-in.

Теперь плагин, который был ранее доступен только на VMware Labs, стал частью решения VMware Virtual SAN 6.1. Теперь вся необходимая информация о жизнедеятельности кластера хранилищ видна в VMware vSphere Web Client:

8. Virtual SAN Management Pack for vRealize Operations.

Теперь для решения vRealize Operations есть отдельный Virtual SAN Management Pack, который позволяет осуществлять мониторинг кластера хранилищ и своевременно решать возникающие проблемы:

Более подробно о решении VMware Virtual SAN 6.1 можно узнать на этой странице. О доступности решения для загрузки будет объявлено несколько позже.

В ближайшее время мы расскажем еще о нескольких интересных анонсах с VMworld 2015 - stay tuned.

В середине августа мы писали про утилиту VMware ESXi Embedded Host Client, которая возвращает полноценный веб-клиент для сервера VMware ESXi с возможностями управления хостом и виртуальными машинами, а также средствами мониторинга производительности. Разработчики получили очень много фидбэка, в результате чего было решено ударными темпами сделать вторую версию, новые возможности которой мы здесь приводим.

Итак, что нового в VMware ESXi Embedded Host Client 2:

Хост ESXi

• Улучшенное представление производительности в интерфейсе
• Композитная метрика CPU/память на одном графике

Виртуальные машины

• Поддержка снапшотов
• Поддержка отображения консоли в полноэкранном режиме
• Поддержка функции обрезания консоли до удобного представления (shrink)
• Возможность создания гостевой машины с Mac OS

Хранилища

• Полноценный файловый браузер (операции copy/move/delete/create directory/upload/download)
• Возможность зарегистрировать ВМ из контекстного меню виртуальной машины
• Возможность создания/монтирования хранилищ NFS
• Создание и расширение хранилищ VMFS (только для ранее неразмеченных дисков)
• Опреации Mount/Unmount для VMFS

Сетевое взаимодействие

• Вывод правил сетевого экрана (пока в режиме read-only)

Основные возможности

• По двойному клику на заголовок окна - оно увеличивается
• Поддержка перетаскивания границы с зажатым "Alt" для изменения размера окна
• Возможность переопределить локаль (но пока официально поддерживается только en-US)
• Указание таймаута сессии с клиентом

Обновляться очень просто - надо просто обновить один vib-пакет, в котором распространяется веб-клиент для ESXi:

[root@mini:~] esxcli software vib update -v /esxui-3015331.vib
Installation Result
Message: Operation finished successfully.
Reboot Required: false
VIBs Installed: VMware_bootbank_esx-ui_0.0.2-0.1.3015331
VIBs Removed: VMware_bootbank_esx-ui_0.0.2-0.1.2976804
VIBs Skipped:

Скачать ESXi Embedded Host Client 2 можно по этой ссылке.

На днях компания Veeam выпустила обновленную версию продукта для комплексного мониторинга и решения проблем в виртуальной среде Veeam Management Pack v8 for System Center.

Напомним, что прошлая версия Veeam MP 7 вышла еще летом прошлого года, поэтому самое время обновить данный продукт.

Новые возможности Veeam Management Pack v8 for System Center:

• App-to-metal visibility

Это основная функция решения, которая позволяет организовать отслеживание всех компонентов физической и виртуальной инфраструктуры и связей между ними. Ниже раскрывается сущность этих улучшений, в следующих версиях эти функции будут совершенствоваться.

• Полная поддержка VMware vSphere 6 - теперь поддерживаются все новые возможности, такие как Virtual Volumes Datastores (VVOLs), компоненты vCenter, лицензирования и сетевого взаимодействия.

• Улучшения Veeam Task Manager for Hyper-V - в новом таск-менеджере поддерживаются виртуальные машины на хранилищах SMB 3.0, а также новые метрики, такие как CPU dispatch time. Кроме того, теперь есть представления кластера Hyper-V и полная совместимость с метриками System Center Virtual Machine Manager и Operations Manager.

• Veeam Morning Coffee Dashboard - новое представление с удобной суммарной информацией по инфраструктуре, на которое первым делом смотрит системный администратор за чашкой утреннего кофе. Отчет Morning Coffee содержит такие показатели, как "VM density" (плотность ВМ на хосте) и уровень нагрузки на вычислительные ресурсы и системы хранения. 

• Capacity planning and right sizing - теперь функции планирования мощностей виртуальной инфраструктуры значительно расширились и теперь содержат следующие сценарии и представления:

- Host Failure Modeling (моделирование ситуации отказа хоста)
- Performance Forecast for vSphere Datastores (прогноз производительности для хранилищ vSphere)
- Performance Forecast for Hyper-V Storage (прогноз производительности для систем хранения Hyper-V)
- Performance Forecast for vSphere and Hyper-V Clusters (прогноз производительности для кластеров vSphere и Hyper-V)
- Virtual Machine Capacity Prediction (прогноз использования ресурсов виртуальными машинами)
- Resize VMs to reclaim resources (перераспределение ресурсов виртуальных машин)
- Capacity planning for hybrid cloud (планирование ресурсов для гибридного облака)
- Capacity planning for Veeam Backup Repositories (планирование ресурсов для репозиториев Veeam Backup & Replication)

• Улучшения планирования для Microsoft Azure или VMware vCloud Air

Отчет для планирования ресурсов был обновлен в соответствии с особенностями Azure и vCloud Air, и теперь с его помощью можно точно прогнозировать количество и тип ресурсов для переноса рабочих нагрузок в облако.

• Улучшения отслеживания снапшотов

Забытые снапшоты и контрольные точки могут быстро разрастаться, занимать дисковое пространство и снижать производительность системы. С помощью "тепловых карт" (heat maps) вы сможете узнать, для каких виртуальных машин есть снапшоты и контрольные точки. Также доступен подробный отчет по иерархии снимков состояния, с указанием даты создания и комментариев.

Прочие улучшения:

• Улучшенная визуализация топологий виртуальных ресурсов
• Улучшенная видимость объектов Veeam Backup and Replication

Больше подробностей о Veeam Management Pack v8 for System Center на русском языке можно узнать на этой странице. Скачать продукт можно по этой ссылке.